«پایان اتکا به پنجرهٔ متنی»؛ رویکرد جدید Telnyx برای تداوم حافظه

تصور کنید یک عامل پشتیبانی درست در لحظه‌ای که جلسه تمام می‌شود، شناسهٔ حساب شما را فراموش کند؛ در این حالت، ابزار شما به‌جای کمک، تبدیل به یک نقطهٔ ضعف می‌شود. شرکت Telnyx در ۷ اکتبر ۲۰۲۶ با معرفی یک معماری حافظهٔ پایدار، این شکاف تداوم را پر کرد و با موفقیت حافظهٔ موقت گفتگو را از ذخیره‌سازی بلندمدت حقایق جدا کرد.

بیشتر عامل‌های هوش مصنوعی به پنجرهٔ زمینه (Context Window) — مثل میز کاری که جا برای چند ورق دارد، نه برای کل کتابخانه — متکی هستند که در واقع همان حافظهٔ کوتاه‌مدت است. طبق گزارش‌های فنی، وقتی این پنجره پاک می‌شود یا جلسه منقضی می‌گردد، عامل به نقطهٔ صفر بازمی‌گردد. این اتفاق کاربر را مجبور می‌کند هر بار ترجیحات، روش‌های تماس و مشکلات قبلی خود را تکرار کند. برای مثال، ممکن است کاربر پیش از این روش تماس ترجیحی، یک شناسهٔ حساب، پیکربندی خاص محصول یا گزارش مفصلی از یک مشکل قبلی را ارائه داده باشد. بدون حافظهٔ پایدار، جلسهٔ بعدی از صفر آغاز می‌شود و عامل دوباره همان اطلاعات را درخواست می‌کند.

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، مدیریت داده‌های کاربر در لایه‌های مختلف حیاتی است. برای حل این مشکل، Telnyx یک API حافظهٔ عامل ارائه داده است که با خاطرات مانند دارایی‌های بادوام برخورد می‌کند. به‌جای پر کردن پرامپت با تمام تاریخچهٔ گفتگو — که باعث اتلاف توکن (Token) و افزایش نویز در پاسخ‌ها می‌شود — این سیستم فقط حقایق ضروری را استخراج کرده و در یک پروفایل اختصاصی ذخیره می‌کند. این الگو به عامل تداوم می‌بخشد، بدون اینکه نیاز باشد هر گفتگوی قبلی به طور کامل در پرامپت قرار گیرد. این رویکرد در تضاد با روش‌های سنتی است که در آن‌ها توسعه‌دهندگان از ابزارهایی مانند LangChain برای پیاده‌سازی حافظه استفاده می‌کردند تا تداوم گفتگو را مدیریت کنند.

گردش‌کار سه‌مرحله‌ای حافظه

بر اساس مستندات توسعه‌دهندگان Telnyx، این فرآیند برای تضمین یکپارچگی داده‌ها از یک خط لولهٔ ناهمگام (Asynchronous Pipeline) پیروی می‌کند و از سه مرحلهٔ متمایز می‌گذرد:

• جذب (Ingestion): عامل متن گفتگو را به نقطهٔ پایانی /ingest می‌فرستد. سیستم به‌جای بازگرداندن فوری حافظه، یک operation_id برای یک شغل نوشتاری ناهمگام صادر می‌کند و وضعیت 202 Accepted را برمی‌گرداند. یک پاسخ معمولی شامل operation_id ،profile_id ،session_id و یک source_id است.
• نظارت (Polling): چون استخراج حقایق زمان‌بر است، برنامه باید نقطهٔ پایانی /operations را بررسی کند. وضعیت عملیات از pending به processing و در نهایت به completed تغییر می‌کند. در محیط‌های عملیاتی، برای جلوگیری از انتظار ابدی، باید مهلت زمانی (Timeout) تعیین شود؛ برای مثال، در پیاده‌سازی نمونه، نظارت پس از ۶۰ ثانیه متوقف شده و یک خطا صادر می‌شود.
• بازیابی (Recall): پس از اتمام عملیات، عامل از نقطهٔ پایانی /recall استفاده می‌کند. با ارسال یک پرس‌وجوی زبان طبیعی، سیستم فقط مرتبط‌ترین حقایق را که بر اساس امتیاز ارتباط (Relevance Score) رتبه‌بندی شده‌اند، بازمی‌گرداند. پاسخ حاوی خودِ حقیقت استخراج‌شده است و نیازی نیست برنامه در متن اصلی گفتگو جستجو کند.

معماری فنی و جداسازی داده‌ها

این سامانه برای جلوگیری از نشت داده‌ها و تضمین مقیاس‌پذیری، از یک ساختار سلسله‌مراتبی استفاده می‌کند. مدل حافظهٔ عامل بر چندین مفهوم کلیدی استوار است:

• فضای نام (Namespace): یک مرز جداسازی برای یک برنامه یا محیط خاص. فضاهای نام سفارشی باید پیش از استفاده ایجاد شوند، هرچند یک فضای نام default بدون نیاز به تجهیزات جداگانه در دسترس است.
• پروفایل (Profile): شخص یا موجودیتی که خاطرات توصیف‌کنندهٔ آن است. در یک برنامهٔ واقعی، از شناسهٔ حساب مشتری، شناسه‌ تماس‌گیرنده یا شماره تلفن به عنوان profile_id استفاده می‌شود (مثلاً user_123).
• منبع (Source): جلسهٔ اصلی یا حقیقت خاصی که به API ارسال شده است.
• خاطره (Memory): یک حقیقت واحد که از یک منبع استخراج شده است.
• عملیات (Operation): یک شغل نوشتاری ناهمگام که می‌توان پیشرفت آن را تا تکمیل ردیابی کرد.

در این ساختار، پروفایل‌ها به عنوان شناسه‌ساز اصلی موجودیت عمل می‌کنند. این امر تضمین می‌کند که خاطرات «کاربر الف» هرگز به جلسه «کاربر ب» نشت نکند. برای مثال، یک توسعه‌دهنده می‌تواند از فضای نامی به نام production-support و پروفایلی به نام customer_1024 استفاده کند تا مرزهای سخت بین محیط‌ها و کاربران حفظ شود. این جداسازی دقیق، مشابه استراتژی‌هایی است که در پیاده‌سازی حافظه بلندمدت با استفاده از Postgres و pgvector برای مدیریت داده‌های برداری در محیط‌های .NET به کار می‌رود.

جزئیات پیاده‌سازی API

تمام نقاط پایانی مربوط به آدرس https://api.telnyx.com/v2/ai/memory هستند. گردش‌کار از سه فراخوانی اصلی بهره می‌برد:

۱. POST /namespaces/{namespace}/profiles/{profile_id}/ingest: برای ارسال پیام‌ها. در یک سناریوی پشتیبانی، این ممکن است شامل متنی باشد که کاربر در آن می‌گوید: «روش تماس ترجیحی من ایمیل است به آدرس [email protected]».
۲. GET /namespaces/{namespace}/operations/{operation_id}: برای ردیابی شغل نوشتاری. سیستم وضعیت‌های نهایی شامل completed (تکمیل‌شده)، failed (شکست‌خورده) و cancelled (لغو شده) را شناسایی می‌کند.
۳. POST /namespaces/{namespace}/profiles/{profile_id}/recall: برای پرس‌وجو از پروفایل. پرس‌وجویی مانند «روش تماس ترجیحی کاربر چیست؟» با مقدار top_k برابر ۱۰، نتایج رتبه‌بندی شده را بازمی‌گرداند.

یک شیء حافظهٔ خروجی شامل یک ID منحصربه‌فرد (مثلاً mem_abc123)، متن استخراج‌شده، یک برچسب زمانی ثبت (مثلاً 2026-10-05T12:00:05Z) و یک امتیاز ارتباط (مثلاً 0.92) است.

حفاظ‌های محیط عملیاتی

برای ساخت یک عامل آمادهٔ تولید، Telnyx بر روی چندین حفاظ حیاتی تأکید کرده است:

• رمزگذاری URL: شناسه‌های مسیر مانند profile_id باید با استفاده از urllib.parse.quote رمزگذاری شوند تا کاراکترهای رزرو شده باعث شکست مسیر درخواست نشوند.
• اعتبارسنجی ورودی: API محدودیت‌های سختی را برای جلوگیری از خطاها اعمال می‌کند. این‌ها شامل حداکثر ۱۲۸ کاراکتر برای session_id ،طول پرس‌وجو بین ۱ تا ۴۰۹۶ کاراکتر و مقدار top_k بین ۱ تا ۱۰۰ است.
• تأیید وضعیت: توسعه‌دهندگان هشدار یافته‌اند که بلافاصله پس از جذب، اقدام به بازیابی نکنند. اگر عملیات به وضعیت completed نرسیده باشد، بازیابی یک لیست خالی برمی‌گرداند. این چرخهٔ حیات صریح به برنامه‌ها اجازه می‌دهد بین نوشتاری که هنوز در حال پردازش است و نوشتاری که شکست خورده یا لغو شده، تمایز قائل شوند.
• استراتژی‌های حذف: برای رعایت قوانین حریم خصوصی داده‌ها، API شامل نقاط پایانی برای حذف منابع تکی یا کل پروفایل‌ها است. این قابلیت به برنامه اجازه می‌دهد در صورت نیاز، هر آنچه به یک پروفایل مرتبط است را پاک کند.

کاربردهای عملی

این الگو نحوه تعامل عامل‌ها را در کانال‌های مختلف ارتباطی تغییر می‌دهد. چون حافظه به شناسهٔ پروفایل گره خورده و نه به یک رشتهٔ چت خاص، کانال ارتباطی می‌تواند تغییر کند اما مدل حافظه ثابت بماند. پیامک (SMS)، صوت، ایمیل و چت مرورگر همگی می‌توانند به یک شناسه‌ پروفایل ختم شوند.

کاربردهای رایج عبارتند از:

• پشتیبانی مشتری: عامل‌هایی که مشکلات قبلی و ترجیحات خاص کاربر را به یاد می‌آورند.
• دستیاران فروش: ابزارهایی که بستر حساب کاربری را در چندین گفتگو حفظ می‌کنند.
• عامل‌های زمان‌بندی: سیستم‌هایی که در دسترس بودن یا ترجیحات ارتباطی را به یاد می‌آورند.
• عامل‌های صوتی: بات‌هایی که تماس‌گیرندگان قدیمی را فوراً شناسایی می‌کنند.
• کمک‌خلبان‌های داخلی (Internal Copilots): ابزارهایی که زمینه‌های کاری خاص هر کاربر را حفظ می‌کنند.

این چرخش، صنعت را از توهم «پرامپت‌های طولانی‌تر» دور می‌کند. یک پنجرهٔ زمینهٔ عظیم، جایگزینی برای پایگاه دادهٔ حقایق نیست. زمینهٔ پرامپت موقتی است، اما حافظهٔ پایدار، بادوام است. با بازیابی تنها k-برترِ خاطرات مرتبط، عامل‌ها دقیق‌تر و مقرون‌به‌صرفه‌تر باقی می‌مانند.

برای توسعه‌دهندگان، این پیاده‌سازی عمداً سبک طراحی شده است. این سیستم تنها به یک کلید API شرکت Telnyx نیاز دارد و نیازی به شماره تلفن، پروفایل پیام‌رسان یا پایگاه‌داده برداری (Vector Database) جداگانه نیست. نمونه کامل کد در گیت‌هاب در مسیر github.com/team-telnyx/telnyx-code-examples/tree/main/persistent-ai-agent-memory در دسترس است.

گام بعدی شما

• اگر از عامل‌های پشتیبانی استفاده می‌کنید، معماری «استخراج حقیقت» را به‌جای ارسال کل تاریخچه به مدل امتحان کنید.
• برای کاهش هزینه استنتاج، مقدار top_k را در بازیابی حافظه بهینه کنید تا فقط حیاتی‌ترین داده‌ها وارد پرامپت شوند.
• استراتژی حذف داده‌های پروفایل را با قوانین GDPR یا قوانین محلی حریم خصوصی تطبیق دهید.

اما تأثیر این حافظه بر روی مدل‌های استدلالی پیچیده‌تر حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی مدل‌های Reasoning مراجعه کنید.