چطور تداخل داده‌های نامرتبط در حافظهٔ شخصی هوش مصنوعی حذف شود

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

به نقل از تحلیل فنی مفصلی که در ۱۶ اکتبر ۲۰۲۶ در وب‌سایت dev.to منتشر شد، تکیه صرف بر بردار معنایی (Embedding) — که مثل کارت معرفی عددی برای هر واژه است و می‌گوید این کلمه همسایه چه کلمات دیگری است — توهمی از حافظه ایجاد می‌کند که در برابر فشار داده‌های واقعی می‌شکند. برای درک عمیق‌تر این فرآیند، می‌توانید سازوکار تبدیل معنای متن به مختصات نقشه‌ای در Embeddings را بررسی کنید. بسیاری از توسعه‌دهندگان با پایگاه‌های داده برداری مانند بانک‌های حافظه جادویی برخورد می‌کنند. آن‌ها فرض می‌کنند اگر دو قطعه متن «از نظر معنایی شبیه» باشند، هوش مصنوعی لزوماً متن درست را بازیابی می‌کند. اما در واقعیت، جست‌وجوی برداری یک مسئله ریاضی برای یافتن نزدیک‌ترین همسایه (Nearest-Neighbor) است، نه درکی شناختی از مفهوم «مرتبط بودن».

وقتی یک لیست خرید از کلماتی مثل «در انتظار» (pending)، «آیتم‌ها» (items)، «نیاز به بررسی» (need to check) یا «پیگیری شود» (follow up) استفاده می‌کند، اثر انگشت واژگانی آن تقریباً مشابه یک یادداشت کاری حرفه‌ای می‌شود. مدل برداری این الگوها را می‌بیند و نزدیک‌ترین همسایه را در فضای برداری با اطمینان کامل برمی‌گرداند. این نتیجه از نظر تنها معیاری که مدل می‌شناسد یعنی ریاضیات درست است، اما از نظر معنایی کاملاً غلط است.

همان‌طور که در بحث‌های گذشته ما درباره امنیت مدل‌های بازمتن اشاره کردیم، مدیریت داده‌های ورودی کلید موفقیت هر سیستمی است. برای حل این مشکل، نویسنده این گزارش سیستمی را با استفاده از Qdrant که روی یک حافظه NAS اجرا می‌شد، راه‌اندازی کرد. این ساختار از مدل nomic-embed-text از طریق Ollama برای تولید بردارهای ۷۶۸-بعدی به‌صورت محلی استفاده می‌کند. این معماری باعث می‌شود هزینه‌های API حذف شده و حریم خصوصی داده‌ها کاملاً حفظ شود، هرچند در ابتدا این سیستم نیز دچار همان تله شباهتی شد که بسیاری از سیستم‌های RAG را گرفتار می‌کند. نویسنده خاطرنشان می‌کند که مدل nomic-embed-text در چندین محک عملکردی حتی از ada-002 شرکت OpenAI بهتر عمل می‌کند، در حالی که اجرای آن به‌صورت محلی کاملاً رایگان است.

معماری یک مغز شخصی

این سیستم برای مقداردهی اولیه زمینه (Context Initialization) طراحی شده است. به‌جای اینکه ۱۰ دقیقه وقت صرف توضیح مجدد تاریخچه پروژه، تصمیمات گرفته شده، مواردی که امتحان شده و مواردی که رها شده به یک مدل زبانی بزرگ (LLM) — که مثل کتابخانه‌داری است که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — یک پرس‌وجوی ۵ ثانیه‌ای، زمینه مرتبط را از پایگاه دانش استخراج می‌کند. این رویکرد، بار اضافی دستی برای بازسازی زمینه در ابتدای هر جلسه جدید را حذف می‌کند.

اجزای سیستم و بودجه

• سخت‌افزار: میزبانی Qdrant روی یک دستگاه NAS.
• مدل بردارساز: اجرای محلی nomic-embed-text روی Ollama (بدون تماس با API و بدون هزینه).
• مجموعه‌ها: دو مجموعه مجزا؛ یک پایگاه دانش شخصی شامل هزاران نقطه داده (یادداشت‌های جلسات، نتایج وظایف، خلاصه‌های پروژه) و یک آرشیو پژوهشی برای ثبت لحظه‌ای متون خوانده شده.
• هزینه عملیاتی: هزینه‌های اندک برق ماهانه، فراتر از سخت‌افزاری که از قبل در حال اجرا بوده است.

خط لوله خودکار

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

• پایان جلسه: یک متن پیاده‌شده (Transcript) آماده شده و به یک گره خلاصه‌ساز ارسال می‌شود.
• استخراج: یک گره پس‌زمینه با استفاده از Groq و مدل llama-3.3-70b حقایق و تصمیمات کلیدی را استخراج می‌کند.
• تکه‌بندی: متن به تکه‌های ۳۸۴ توکنی با ۱۵٪ هم‌پوشانی (Overlap) تقسیم می‌شود.
• بردارسازی: مدل nomic-embed-text (از طریق Ollama) بردارهای ۷۶۸-بعدی را تولید می‌کند.
• ذخیره‌سازی: بردارها به‌همراه متادیتای دامنه (Domain Metadata) در Qdrant ذخیره می‌شوند.

ماهیت توهم حافظه

هوش مصنوعی محلی در واقع چیزی را «به یاد نمی‌آورد»، بلکه آن را «بازیابی» می‌کند. کیفیت این بازیابی (Retrieval) تعیین می‌کند که توهم حافظه چقدر واقعی به نظر برسد. وقتی سیستم هزاران نقطه داده داشته باشد، واقعاً کاربردی می‌شود. برای مثال، نویسنده می‌تواند درباره تصمیمات معماری که ماه‌ها پیش گرفته شده بپرسد و استدلال‌های دقیقی که در آن زمان به کار رفته بود را بازیابی کند. این همان توهم حافظه‌ای است که طبق برنامه پیش می‌رود.

تله شباهت کسینوسی

شباهت کسینوسی (Cosine Similarity) زاویه بین دو بردار را اندازه می‌گیرد تا بفهمد جهت آن‌ها در فضای چندبعدی چقدر مشابه است. این روش برای ثبت شباهت معنایی عالی است اما نمی‌تواند بین دامنه‌های مختلف تفاوت قائل شود. در «حادثه لیست خرید»، پرس‌وجویی درباره «وضعیت پیگیری‌های اخیر پروژه» در یک «منطقه زرد» از فضای برداری قرار گرفت.

رتبه‌بندی نتایج جست‌وجو، این شکست را به وضوح نشان داد:

• رتبه ۱: grocery-list-2024-11-15.md (امتیاز: ۰.۸۴۷)
• رتبه ۲: job-applications-november.md (امتیاز: ۰.۸۳۱)
• رتبه ۳: agent-memory-session-notes.md (امتیاز: ۰.۸۰۲)
• رتبه ۴: n8n-job-filter-config.md (امتیاز: ۰.۷۸۹)

این نتایج ثابت می‌کند که شباهت، همان مرتبط بودن نیست. این تمایز هر سیستمی را که مرزهای دامنه (Domain Boundaries) را در نظر نگیرد، از کار می‌اندازد.

معمای اندازه تکه‌ها

یکی از تصمیماتی که در جست‌وجوی برداری بیشترین نادیده گرفته می‌شود، اندازه تکه‌بندی (Chunking) است. نویسنده اشاره می‌کند که اکثر آموزش‌های آنلاین، موازنه بین «زمینه» و «رقیق شدن» (Dilution) را نادیده می‌گیرند. اندازه این تکه‌ها یکی از اثرگذارترین تصمیماتی است که یک توسعه‌دهنده می‌گیرد.

• بسیار کوچک (مثلاً ۶۴ توکن): یک تکه ممکن است فقط یک جمله باشد: «پروژه متوقف شد». این تکه هنگام بازیابی تقریباً بی‌معنی است چون فاقد پاسخ به سوالات «چرا»، «کدام پروژه» و «چه کسی تصمیم گرفت» است.
• بسیار بزرگ (مثلاً ۲۰۴۸ توکن): یک تکه ممکن است شامل ۱۵ موضوع مختلف باشد. بردار سعی می‌کند همه آن‌ها را نمایندگی کند و در نتیجه سیگنال بازیابی در میان تمام محتوای چپانده شده در تکه، رقیق می‌شود.

محدوده بهینه (اعداد تست شده)

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

• یادداشت‌های واقع‌گرایانه و خلاصه‌های پروژه: ۲۵۶ تا ۵۱۲ توکن با ۱۰٪ هم‌پوشانی.
• محتوای گفتگو-محور: ۵۱۲ تا ۱۰۲۴ توکن.
• انتخاب نهایی نویسنده: ۳۸۴ توکن با ۱۵٪ هم‌پوشانی برای پایگاه دانش شخصی.

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

حل شکاف مرتبط بودن

مشکل لیست خرید به این دلیل رخ داد که پایگاه دانش یک فضای تخت (Flat Namespace) و واحد بود. یادآورهای شخصی، تصمیمات زیرساختی و یادداشت‌های پروژه همگی با یک معیار شباهت واحد رقابت می‌کردند. برای حل این مشکل، نویسنده فیلتر دامنه را قبل از جست‌وجوی برداری پیاده کرد.

مکانیزم بازیابی ترکیبی

با افزودن یک فیلد متادیتای دامنه به هر نقطه ذخیره شده — با مقادیری مانند jobs (شغلی)، infra (زیرساخت)، personal (شخصی) و research (پژوهشی) — سیستم اکنون یک فرآیند دو مرحله‌ای را به کار می‌گیرد:

۱. فیلتر متادیتا: پرس‌وجو ابتدا به یک دامنه خاص محدود می‌شود (مثلاً domain = "jobs").
۲. جست‌وجوی برداری: شباهت کسینوسی فقط در این زیرمجموعه فیلتر شده محاسبه می‌شود.

این رویکرد نرخ مثبت کاذب را تقریباً به صفر رساند. قبل از این اصلاح، پرس‌وجویی درباره «وضعیت وظایف اخیر پروژه» در کل مجموعه، اجازه می‌داد لیست خرید به دلیل هم‌پوشانی واژگانی پیروز شود. پس از اصلاح، لیست خرید حتی ارزیابی نمی‌شود چون در استخر کاندیداهای «شغلی» وجود ندارد. اکنون نتیجه درست در هر بار جست‌وجو در بین ۳ نتیجه اول قرار می‌گیرد. این استراتژی در راستای گام‌های عملیاتی برای کاهش خطاهای بازیابی داده قرار دارد که برای بهینه‌سازی خروجی‌های RAG ضروری است.

درس‌هایی برای ساخت حافظه برداری

این تغییر، سیستم را از یک «سوپ از همه چیز» به یک شاخص ساختاریافته تبدیل می‌کند. درس اصلی این است که شباهت معنایی در دامنه‌های غیرمرتبط، مسئله اشتباهی برای حل کردن است. برای کسانی که سیستم‌های مشابه می‌سازند، نویسنده این چک‌لیست را پیشنهاد می‌کند:

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

آنچه آموزش‌ها نمی‌گویند

بیشتر راهنماها فقط مسیرهای موفق (Happy-path) را نشان می‌دهند — مثلاً پرسیدن درباره پاریس و دریافت سندی درباره پاریس. آن‌ها ذکر نمی‌کنند که مدل‌های بردارساز از متون عمومی اینترنت یاد گرفته‌اند. این بدان معناست که واژگان تخصصی دامنه، مانند نام‌های داخلی پروژه‌ها یا کدهای تراکنش SAP، بدون تنظیم دقیق (Fine-tuning) به‌خوبی بردارسازی نمی‌شوند.

علاوه بر این، آموزش‌ها به‌ندرت الگوی فیلتر متادیتا را که شکاف مرتبط بودن را حل می‌کند، پوشش می‌دهند. آن‌ها اغلب این حقیقت را نادیده می‌گیرند که مدل‌های محلی مانند nomic-embed-text می‌توانند در چندین محک عملکردی از مدل‌های تجاری مانند ada-002 شرکت OpenAI پیشی بگیرند و در عین حال رایگان باشند.

جمع‌بندی نهایی

استفاده از Qdrant ابزاری عالی برای این هدف است. میزبانی شخصی روی NAS، آن ۱۰ تا ۱۵ دقیقه زمان تلف شده برای بازسازی زمینه در هر گفتگو را حذف می‌کند. با این حال، مفیدترین بخش این پروژه، همان «لیست خرید» بود؛ چون یک نقص طراحی بنیادین را زودتر از موعد افشا کرد: این فرض غلط که شباهت برداری برابر با مرتبط بودن است.

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

گام بعدی شما

• اگر از RAG استفاده می‌کنید، متادیتای دامنه (Domain) را به بردارهای خود اضافه کنید تا از تداخل موضوعات جلوگیری شود.
• اندازه تکه‌ها را بر اساس نوع داده (گفتگو در برابر مستندات) تغییر دهید و هم‌پوشانی ۱۵ درصدی را فراموش نکنید.
• مدل‌های محلی مثل nomic-embed-text را جایگزین مدل‌های پولی کنید تا هزینه استنتاج را به صفر برسانید.

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