تصور کنید یک استخدام‌کننده در شرکتی بزرگ، ترجیحات خاصی برای مهارت‌ها یا موقعیت جغرافیایی کاندیداها دارد؛ این ترجیحات نباید با پایان هر جلسه چت، از یاد برود. لینکدین با درک این نیاز، حافظه عامل‌های هوشمند را به‌جای یک پایگاه‌داده ساده، به عنوان یک معماری شناختی زنده طراحی کرده است. این رویکرد بر این اصل استوار است که ترجیحات کاربر نباید با بسته شدن یک پنجره گفتگو ناپدید شوند.
به نقل از پراوین بودیگوتلا (Praveen Bodigutla)، پژوهشگر ارشد هوش مصنوعی لینکدین، این سیستم جدید برای ارائه تجربه‌ای شخصی‌سازی‌شده و دارای «وضعیت» (State) برای دستیاران استخدام ساخته شده است. اکثر عامل‌های فعلی یا دچار فراموشی کامل بین جلسات می‌شوند یا سعی می‌کنند تمام تاریخچه را در پنجره متنی (Context Window) — که شبیه میز کاری است که فقط جای چند ورق کاغذ دارد و نه کل کتابخانه — بچپانند؛ اتفاقی که باعث افزایش هزینه‌ها و کند شدن پاسخ‌ها می‌شود. این پدیده را «تورم متن» (Context Bloat) می‌نامند.
لینکدین برای حل این مشکل، از تولید بازیابی‌افزا (RAG) — شبیه دانش‌آموزی که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد — فراتر رفته و یک چرخه مدیریت حافظه ایجاد کرده است که تمام چرخه حیات اطلاعات را از جذب تا هرس کردن مدیریت می‌کند. این سیستم فراتر از یک بازیابی ساده است و به عنوان یک معماری شناختی عمل می‌کند که اطلاعات را جذب، تثبیت، بازیابی و در نهایت پاکسازی می‌کند.
همان‌طور که در تحلیل‌های قبلی ما درباره امنیت و مدیریت داده در مدل‌های زبانی اشاره کردیم، مدیریت بهینه بستر متن، کلید دستیابی به پاسخ‌های دقیق است. در لینکدین، این سیستم باید بفهمد چه چیزی جذب شود، چگونه بازیابی شود و چطور به‌روزرسانی شود تا شخصی‌سازی عمیق اتفاق بیفتد.
زمینه: پیدایش عامل حافظه
لینکدین یک دستیار استخدام توسعه داد تا به استخدام‌کنندگان در مدیریت گردش‌های کاری پیچیده کمک کند. در طول این تعاملات، استخدام‌کنندگان مکرراً ترجیحات خاص خود را بیان می‌کنند و نقش‌های شغلی را اصلاح می‌کنند. آن‌ها فقط فهرستی از مهارت‌ها را ارائه نمی‌دهند، بلکه بازخوردهای مستقیمی درباره کاندیداهای نمایش داده شده می‌دهند.
بودیگوتلا متوجه نوعی «چسبندگی» در این ترجیحات شد. تعریف یک نقش شغلی توسط یک استخدام‌کننده، اغلب به عناوین مشابه یا سایر نقش‌هایی که او مدیریت می‌کند، منتقل می‌شود. برای ایجاد یک تجربه واقعی از «عامل هوشمند»، لینکدین به یک لایه شخصی‌سازی نیاز داشت که مفهوم «وضعیت» (State) را برای عامل فراهم کند. این رویکرد در واقع تلاشی برای تبدیل هوش مصنوعی از یک ابزار کمکی ساده به یک سامانه کنش‌گراست که می‌تواند در محیط‌های عملیاتی پیچیده به جای نقش یک کمک‌خلبان دفتری، عمل کند.
این عامل حافظه فراتر از واکشی ساده عمل می‌کند؛ او هماهنگ‌کننده کل چرخه حیات داده‌های کاربر است. هدف این است که عامل نه تنها یک حقیقت را به یاد آورد، بلکه وضعیت مرتبط با هدف فعلی کاربر را درک کند. این امر هوش مصنوعی را از یک ابزار بدون وضعیت (Stateless) به یک دستیار دائمی تبدیل می‌کند که همگام با نیازهای استخدام‌کننده تکامل می‌یابد.
زمینه: پیشینه مهندسی
ساخت این سیستم نیازمند ترکیبی از مهندسی پلتفرم و پژوهش‌های هوش مصنوعی بود. پیشینه بودیگوتلا بازتاب‌دهنده این رویکرد چندرشته‌ای است؛ او پیش از این به عنوان مهندس پلتفرم در یاهو و توسعه‌دهنده کوانت در یک بانک سرمایه‌گذاری در نیویورک فعالیت کرده است.
پایه تحصیلی او شامل کارشناسی ارشد در ریاضیات مالی و علوم داده از استنفورد و NYU است، جایی که با اساتید برجسته‌ای چون اندرو ان‌جی (Andrew Ng)، کیون چو (Kyun Kyoon Chou) و جفری اولمن (Jeffrey Ullman) همکاری کرده است. تجربیات او در پژوهش‌های مدل‌های گفتگو در پروژه الکسا (Alexa)، به طراحی لایه ارکستراسیون عامل حافظه کمک شایانی کرد.
پشته حافظه چهار لایه
برای شبیه‌سازی شناخت انسانی، لینکدین حافظه عامل خود را به چهار لایه مجزا سازماندهی کرد که هر کدام هدف زمانی و عملکردی متفاوتی دارند:
- حافظه محاوره‌ای (Conversational Memory): ثبت تعاملات لحظه‌ای و ترجیحات جاری در یک جلسه. این به‌روزترین لایه است و منعکس‌کننده وظیفه فعلی و ترجیحات فوری کاربر در یک جلسه زنده است.
- حافظه اپیزودیک (Episodic Memory): لایه پرس‌وجوی زمانی که اجازه می‌دهد عامل، ریشه یک ترجیح سنتز شده را در سوابق و فعالیت‌های واقعی که منجر به آن نتیجه شده، پیدا کند و منشأ داده‌ها را ردیابی کند.
- حافظه رویه‌ای (Procedural Memory): ثبت «چگونگی» گردش کار کاربر. این لایه توازن‌هایی که یک استخدام‌کننده ایجاد می‌کند را ثبت می‌کند؛ مثلاً اولویت دادن به سابقه کار و جنبه‌های خاص نقش شغلی بر موقعیت مکانی و نوع محیط کار، که این اولویت‌ها بین افراد مختلف به‌شدت متفاوت است.
- حافظه معنایی (Semantic Memory): ذخیره‌ساز بلندمدت تجمیعی. این لایه ترجیحات را از چندین جلسه و سطوح مختلف محصول سنتز می‌کند. برای مثال، داده‌های هر دو بخش «دستیار استخدام» و «پلتفرم جست‌وجوی لینکدین» را با هم ترکیب می‌کند.
جزئیات: مکانیسم جذب و بازیابی
استخراج نشانگرهای وضعیت رفتاری از یک جریان داده واحد دشوار است. گردش کار استخدام‌کنندگان غیرخطی است؛ کاربر ممکن است ابتدا یک کاندیدا را ارزیابی کند، سپس به عقب برگردد تا شرح شغلی را اصلاح کند و دوباره به جلو حرکت کند.
جذب و تثبیت (Ingestion and Consolidation):
- تثبیت در لحظه: یک سرویس جذب، تعاملات را تقریباً در لحظه نظارت می‌کند تا متن را فشرده کرده و از تورم آن جلوگیری کند. این امر حیاتی است زیرا فرآیند استخدام شامل مراحل متعددی است: شروع با شرح شغلی، اصلاح آن، بررسی کاندیداها و بایگانی سایرین.
- شناسایی مرزهای جلسه: سیستم باید زیرمجموعه‌های موضوعی تعاملات و مرزهای هر جلسه را شناسایی کند تا اطلاعات قابل کشف و به‌درستی نمایش داده شوند. این موضوع در «عامل‌های عمیق» که کاربران چندین وظیفه مختلف را به‌طور متناوب انجام می‌دهند، دشوارتر است.
- شغل‌های تثبیت آفلاین: پردازش‌های دوره‌ای برای حذف داده‌های تکراری، پیوند دادن داده‌ها با منابع خارجی و حذف ترجیحات قدیمی یا متناقض اجرا می‌شوند. این شغل‌ها حافظه را با اطلاعات تکمیلی تقویت و نویزها را پاک می‌کنند.
- نسبت سیگنال به نویز: سیستم به‌گونه‌ای طراحی شده که صرفه‌جو باشد و فعالیت‌های با سیگنال بالا را ثبت و نویزها را فیلتر کند. در مورد استخدام‌کنندگان، یک فعالیت واحد اغلب سیگنال بالایی دارد که به کاهش نویز در هنگام ذخیره‌سازی کمک می‌کند.
- ارزیابی سه لایه: لینکدین از یک سیستم ارزیابی سه لایه استفاده می‌کند تا مطمئن شود هنگام ذخیره اطلاعات، موجودیت‌ها حفظ شده و ارجاعات (Citations) باقی می‌مانند تا تیم از کیفیت حافظه تجمیع‌شده مطمئن شود.
- منابع جریان داده: سیستم دو منبع اصلی را مصرف می‌کند: تعاملات مستقیم بین استخدام‌کننده و عامل، و فعالیت‌های انجام شده در سایر سطوح محصول لینکدین. در این راستا، بهره‌گیری از داده‌های اختصاصی و ساختاریافته به عنوان یک خندق دفاعی، می‌تواند دقت این مدل‌های سازمانی را در برابر مدل‌های عمومی افزایش دهد.
بازیابی و تازگی (Retrieval and Freshness):
- پرس‌وجوی زمانی: سیستم از بازیابی مبتنی بر EBR استفاده می‌کند تا مرتبط‌ترین اطلاعات را بر اساس گام فعلی استخدام‌کننده در گردش کار فراخوانی کند. این کار با جلوگیری از استخراج تمام فعالیت‌های تاریخی، از تورم متن جلوگیری می‌کند.
- حل تعارض: یک سیاست اولویت‌بندی، تعارضات بین لایه‌های حافظه را مدیریت می‌کند تا تازه‌ترین اطلاعات اولویت داشته باشند. این موضوع زمانی ضروری است که کاربر در میانه گفتگو نظر خود را تغییر دهد.
- پیش‌تجمیع (Pre-aggregation): برای الگوهای استاندارد، مانند اولین ورود کاربر به سیستم، اطلاعات در یک حافظه موقت (Cache) پیش‌تجمیع می‌شوند تا فوراً در دسترس باشند.
- جایگزینی‌های پویا: اگر استخدام‌کننده صراحتاً ترجیحی را تغییر دهد (مثلاً: «دیگر نمی‌خواهم در این شهر استخدام کنم»)، لایه بازیابی باید این سیگنال جدید را بر داده‌های تاریخی اولویت دهد.
- ردیابی و ارجاعات: برای تضمین شفافیت، سیستم برای ترجیحات سنتز شده ارجاع ارائه می‌دهد. این کار مانع از آن می‌شود که عامل ادعا کند کاربر ترجیحی دارد که هرگز بیان نکرده است.
- سیاست‌های تازگی: سیستم از سیاست‌های پاکسازی ساده‌ای استفاده می‌کند، مانند حذف داده‌های قدیمی‌تر از ۶ ماه یا یک سال، به شرطی که آن اطلاعات قبلاً در حافظه بلندمدت سنتز شده باشند.
چرا GraphRAG در مقیاس بالا شکست خورد؟
در ابتدا، تیم از GraphRAG برای مدیریت حافظه بلندمدت استفاده می‌کرد. با این حال، آن‌ها دریافتند که این معماری برای مقیاس عظیم لینکدین ناپایدار است. GraphRAG برای شناسایی پیوندها بین گره‌ها به تعداد بیش از حد فراخوانی‌های LLM نیاز داشت و هر به‌روزرسانی مستلزم بازسازی گران‌قیمت کل ذخیره حافظه بود.
برای رفع این مشکل، لینکدین به یک سازماندهی سلسله‌مراتبی درختی تغییر مسیر داد. این ساختار با سلسله‌مراتب ذاتی داده‌های استخدام همخوانی دارد:
۱. سطح برگ: ترجیحات پروژه‌های فردی (دانگ‌رین‌ترین گره).
۲. سطح استخدام‌کننده: ترجیحات تجمیع‌شده برای یک کاربر واحد.
۳. سطح گروه (Cohort): اطلاعات مشترک بین چندین استخدام‌کننده در یک شرکت که برای نقش‌های مشابه استخدام می‌کنند. این امر به استخدام‌کنندگان جدید اجازه می‌دهد تا با استفاده از یک نقشه راه از نحوه اولویت‌بندی شرکتشان، تجربه خود را سریع‌تر شروع کنند.
این ساختار درختی اجازه بهینه‌سازی به‌روزرسانی‌های افزایشی را می‌دهد. سیستم می‌تواند گره برگ یا شاخه خاصی را که نیاز به به‌روزرسانی دارد شناسایی کرده و آن تغییر را به سمت بالا منتقل کند، بدون اینکه کل ایندکس را مجدداً محاسبه کند. این تغییر منجر به کاهش شدید تعداد فراخوانی‌های LLM و کاهش هزینه کلی حفظ وضعیت کاربر شد.
خط لوله ETL عامل‌محور
بودیگوتلا این سیستم را به عنوان یک «ETL برای عصر عامل‌های هوشمند» توصیف می‌کند. به‌جای ذخیره لاگ‌های خام، عامل حافظه از یک سرویس جذب برای تثبیت تعاملات استفاده می‌کند. این فرآیند تضمین می‌کند که حافظه صرفاً انبار داده نباشد، بلکه یک دارایی ساختاریافته باشد. این رویکرد مهندسی دقیق، پاسخی به این چالش است که چرا بسیاری از عامل‌های سازمانی بدون زیرساخت‌های پایداری در زمان اجرا با شکست مواجه می‌شوند.
برای حفظ عملکرد، تیم چندین بهینه‌سازی مهندسی را اجرا کرد:
- برنامه‌ریزی موازی: لایه ارکستراسیون از برنامه‌ریزی موازی یک‌مرحله‌ای برای شناسایی ابزارهای حافظه مورد نیاز استفاده می‌کند، به‌جای برنامه‌ریزی متوالی که باعث کاهش تأخیر (Latency) می‌شود.
- بودجه‌بندی تأخیر: عامل حافظه به ۱۰ تا ۲۰ درصد از کل بودجه تأخیر پاسخ محدود شده است تا تجربه کاربر روان باقی بماند، زیرا اپلیکیشن باید داده‌ها را از منابع دیگر نیز فراخوانی کند.
- بهینه‌سازی‌های استنتاج: تیم از کش‌های پیشوندی (Prefix Caches) و پیش‌پُرکردن تکه‌ها (Chunk Prefills) در سطح موتور سرویس‌دهی vLLM برای کاهش تأخیر کلی استفاده می‌کند.
- خروجی‌های ساختاریافته: با اجبار LLM به پیروی از یک فرمت API سخت‌گیرانه و محدود کردن توکن‌های استدلال، آن‌ها از تولید متون دلخواه و طولانی که باعث افزایش تأخیر می‌شود، جلوگیری می‌کنند.
- فراخوانی‌های انتخابی LLM: سیستم از استدلال‌های پیچیده برای پرس‌وجوهای ساده اجتناب می‌کند. اگر پاسخی در همان متن گفتگو موجود باشد، سیستم فرآیند کامل استدلال حافظه را نادیده می‌گیرد.
- رابط‌های استاندارد: در حالی که ساختار حافظه (درختی در مقابل گراف) می‌تواند برای برنامه‌های مختلف سفارشی شود، لایه‌های ارکستراسیون، استدلال و سنتز از طریق APIهای ثابت، استاندارد باقی می‌مانند.
حاکمیت و حریم خصوصی
عملیات در مقیاس لینکدین نیازمند جداسازی سخت‌گیرانه داده‌ها است. سیستم از معماری چندمستاجری (Multi-tenancy) استفاده می‌کند تا هر اپلیکیشن ذخیره‌ساز داده ایزوله‌ای داشته باشد. دسترسی‌ها از طریق اعتبارنامه‌های امضا شده کنترل می‌شوند و گره‌های حافظه با برچسب مالک (Owner) علامت‌گذاری می‌شوند تا از نشت اطلاعات بین کاربران یا گروه‌های غیرمجاز جلوگیری شود.
این معماری اجازه می‌دهد برای هر کاربر یک حافظه شخصی‌سازی‌شده وجود داشته باشد و در عین حال، در صورت اجازه، «هوش دامنه شخصی‌سازی‌شده» برای یک گروه ایجاد شود. این یعنی در حالی که هر استخدام‌کننده وضعیت خاص خود را دارد، همچنان می‌تواند از هوش جمعی سازمان خود بهره‌مند شود.
آینده وضعیت عامل‌های هوشمند
لینکدین اکنون در حال بررسی سیستم‌های فایل مجازی برای انتزاع حافظه است تا با قدرتمندتر شدن LLMها، داده‌ها قابل کشف‌تر شوند. تیم همچنین بر «انتساب» (Attribution) تمرکز کرده است؛ یعنی توانایی ارجاع دقیق به اینکه کدام تعامل خاص منجر به یک ترجیح سنتز شده است تا شفافیت و کنترل بیشتری به کاربران داده شود.
سایر حوزه‌های سرمایه‌گذاری فعال عبارتند از:
- مرزهای جلسه پویا: بهینه‌سازی بیشتر نحوه شناسایی و فشرده‌سازی مرزهای تعامل برای کاهش اصطکاک.
- بهینه‌سازی سرتاسری (End-to-End): حرکت از بهینه‌سازی لایه‌های مجزا به سمت بهینه‌سازی کل چرخه حیات حافظه به عنوان یک واحد واحد.
- کنترل کاربر: اجازه دادن به کاربران برای اینکه صراحتاً به عامل بگویند ترجیح خاصی را «فراموش» کند یا به‌طور دستی جفت‌های کلید-مقدار را به پروفایل خود اضافه کنند.
- طرح‌های وزن‌دهی: بررسی نحوه تکامل پویا یک طرح وزن‌دهی برای ترجیحاتی که چندین بار بیان شده‌اند، تا نیاز کاربران به تکرار حرف‌هایشان کاهش یابد.
- ارزیابی نماینده: سرمایه‌گذاری در استراتژی‌های ارزیابی قدرتمند برای ثبت تغییرات در الگوهای تعامل با پیچیده‌تر شدن عامل‌ها.
این تغییرات نشان می‌دهد که آینده عامل‌های هوش مصنوعی تنها در مدل‌های بزرگتر نیست، بلکه در «مغزهای دوم» پیچیده‌تری است که می‌توانند وضعیت را با کارایی یک پایگاه‌داده سنتی و ظرافت حافظه انسانی مدیریت کنند.
گام بعدی شما
- اگر در حال توسعه عامل‌های AI هستید، به‌جای ذخیره لاگ‌های خام، یک لایه «سنتز حافظه» برای تبدیل تعاملات به ترجیحات ساختاریافته طراحی کنید.
- برای کاهش هزینه API، ساختارهای درختی را برای داده‌هایی که ذاتاً سلسله‌مراتی هستند (مثل سازمان‌ها یا دسته‌بندی محصولات) جایگزین گراف‌های پیچیده کنید.
- از تکنیک‌های Parallel Planning در لایه ارکستراسیون برای کاهش تأخیر (Latency) در پاسخ‌های عامل استفاده کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell و تأثیر آن‌ها بر استنتاج مدل‌های حجیم مراجعه کنید.
گفتگو