تصور کنید یک برنامه‌نویس ارشد را که به جای خواندن هزاران خط کد، ابتدا به یادداشت‌های سازمان‌یافته‌ای مراجعه می‌کند که معماری کل سیستم را توضیح می‌دهد. این تفاوت میان «جست‌وجوی خام» و «دانش تثبیت‌شده» است که اکنون در تقابل میان دو رویکرد مدیریت دانش در عامل‌های هوش مصنوعی قرار گرفته است.
بحث بر سر این است که یک عامل (Agent) چگونه باید با یک پایگاه کد یا مستندات حجیم تعامل کند. از یک سو تولید بازیابی‌افزا (RAG) — شبیه دانش‌آموزی که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد — و از سوی دیگر «ویکی‌های هوش مصنوعی» (LLM Wiki) قرار دارند. این دو رویکرد بر اساس فلسفه‌های بنیادین متفاوتی عمل می‌کنند: یکی یک فرآیند جست‌وجوی گذرا است و دیگری یک فرآیند تجمعی برای ساخت دانش.
همان‌طور که در تحلیل‌های پیشین ما درباره‌ی حافظهٔ بلندمدت مدل‌ها اشاره کردیم، چالش اصلی همواره تعادل میان دقت و هزینه بوده است. برای سنجش این موضوع، آزمونی دقیق با استفاده از عامل Claude Code روی یک پایگاه کد واقعی اجرا شد تا عملکرد، هزینه و صحت پاسخ‌ها در دو حالت «بازیابی عامل‌محور» (بدون ویکی) و «ویکی نگهداری‌شده» اندازه‌گیری شود. هدف این بود که مشخص شود وقتی یک عامل با مجموعه‌ای از پرسش‌های فنی روبروست، کدام روش در ارائه پاسخ‌های دقیق‌تر با هزینه کمتر موفق‌تر است.
طبق مستندات این آزمایش، مکانیزم‌ها به این صورت عمل می‌کنند: RAG در رایج‌ترین شکل خود، شامل یک بازیاب است که تکه‌های مرتبط از مستندات را از طریق شباهت جاسازی‌ها (Embedding Similarity) می‌یابد و آن‌ها را در پرامپت قرار می‌دهد. اما یک گونه مدرن‌تر به نام «بازیابی عامل‌محور»، دیتابیس‌های برداری را کاملاً حذف می‌کند. در این حالت، عامل از ابزارهایی مثل grep یا دستورات خواندن فایل استفاده می‌کند تا در یک حلقه، مخزن کد را کاوش کند تا پاسخ را بیابد. این فرآیند «بدون وضعیت» (Stateless) است؛ یعنی هر پرسش جدید از صفر شروع می‌شود و کد منبع تغییرناپذیر را دوباره می‌خواند.
در مقابل، یک ویکی هوش مصنوعی، مجموعه‌ای از صفحات مارک‌داون است که خودِ عامل می‌نویسد و به‌روز می‌کند. هر صفحه یک مفهوم، یک تصمیم طراحی یا یک ماژول را توصیف می‌کند و هر ادعا در آن به کد منبع ارجاع داده شده است. وقتی عامل با پرسشی روبرو می‌شود که پاسخ آن در ویکی نیست، ابتدا کد منبع را می‌خواند و سپس یافته‌های خود را به صورت سنتز شده به ویکی اضافه می‌کند. این کار یک لایه دائمی و تکاملی از دانش ایجاد می‌کند که پرسش‌های بعدی می‌توانند بدون نیاز به خواندن مجدد کد خام، از آن بهره ببرند.
این آزمایش شامل پرسیدن چهار پرسش فنی استاندارد و یک پرسش پیچیده سنتزی بود. برای چهار پرسش اول — که عمدتاً واقعیت‌محور بودند و در نقاط مشخصی از کد قابل مکان‌یابی بودند — روش بازیابی عامل‌محور (بدون ویکی) به‌طور مداوم سریع‌تر و ارزان‌تر بود. چون عامل می‌توانست به سادگی برای یک کلمه کلیدی grep کند و فایل مربوطه را بخواند، در گام‌های کمتری به پاسخ می‌رسید.
اما در روش ویکی، عامل باید ابتدا فهرست ویکی را می‌خواند، به یک صفحه خاص هدایت می‌شد و سپس احتمالاً اطلاعات را با کد منبع تأیید می‌کرد. این سربار عملیاتی منجر به مصرف توکن‌های بیشتر و افزایش تأخیر (Latency) شد، بدون اینکه افزایش متناظری در دقت پاسخ‌ها ایجاد کند. در واقع برای یافتن واقعیت‌های نقطه‌ای، ویکی یک لایه اضافی و کندکننده بود.
اما در پرسش پنجم که نیاز به سنتز اطلاعات داشت، ورق برگشت. این پرسش پاسخی را می‌طلبید که به طور صریح در هیچ تک‌فایلی نوشته نشده بود، بلکه یک ویژگی برآمده (Emergent Property) از معماری کل سیستم بود. روش بازیابی عامل‌محور در اینجا به شدت دچار مشکل شد؛ زیرا عامل مجبور بود در میان فایل‌های متعدد سرگردان شود و اغلب رشتهٔ منطق را گم می‌کرد یا ارتباط بین ماژول‌های پراکنده را نمی‌دید.
در مقابل، ویکی هوش مصنوعی پیروز مطلق بود. چون عامل پیش‌تر الگوهای معماری را در یک صفحه اختصاصی سنتز و ثبت کرده بود، توانست پاسخ این پرسش پیچیده را تقریباً آنی بدهد. ویکی در اینجا مانند یک «کش» (Cache) از درک انسانی عمل کرد و شکاف میان داده‌های خام و دانش مفهومی را پر کرد. این نشان داد که ویکی می‌تواند مفاهیمی را ذخیره کند که در کد خام به صورت پراکنده هستند.
این نتایج یک تمایز حیاتی را روشن می‌کند: RAG برای «بازیابی» (Retrieval) بهینه شده است، در حالی که ویکی برای «سنتز» (Synthesis). اگر هدف اصلی یافتن تعریف یک تابع خاص یا یک مقدار تنظیمات (Configuration) است، سربار نگهداری ویکی یک نقطه ضعف و هزینه اضافی است. رویکرد «بدون ویکی» برای شناسایی دقیق واقعیت‌ها، سبک‌تر و کارآمدتر است.
اما برای استدلال‌های سطح بالا — مثل توضیح دلیل انتخاب یک الگوی طراحی خاص در پنج ماژول مختلف — ویکی یک میان‌بر شناختی ایجاد می‌کند که بازیابی خام هرگز به آن نمی‌رسد. ویکی، عامل را از یک موتور جست‌وجو به یک متخصص موضوعی تبدیل می‌کند که پژوهش‌های قبلی خود را به یاد می‌آورد و نیازی به یادگیری مجدد مفاهیم در هر جلسه (Session) ندارد.
از منظر هزینه-فایده، «مالیات ویکی» همان هزینه جاری نگهداری است. هر بار که کد منبع تغییر می‌کند، ویکی باید به‌روز شود تا از توهم (Hallucination) — وقتی مدل با اطمینان چیزی می‌گوید که دیگر در کد وجود ندارد یا قدیمی شده است — جلوگیری شود. این امر مستلزم آن است که عامل «اجراهای نگهداری» (Maintenance Runs) انجام دهد و ویکی را با آخرین کامیت‌ها تطبیق دهد.
برای تیم‌هایی با پایگاه کدهای به‌شدت متغیر و سریع، این هزینه نگهداری ممکن است از مزایای سنتز سریع بیشتر شود. اما برای سیستم‌های پایدار یا حوزه‌هایی با منحنی یادگیری تند برای برنامه‌نویسان انسانی، ویکی به یک مستند Onboarding خودکار تبدیل می‌شود که در لحظه تکامل می‌یابد و دانش سازمانی را حفظ می‌کند.
در نهایت، انتخاب بین RAG و ویکی به ماهیت پرسش‌ها بستگی دارد. اگر ۹۰٪ حجم کار از نوع «این مورد کجا تعریف شده است؟» و ۱۰٪ از نوع «این سیستم از نظر مفهومی چگونه کار می‌کند؟» باشد، RAG عامل‌محور برنده مطلق است. اما اگر حجم کار به سمت تحلیل معماری و سنتزهای بین-عملکردی تغییر کند، سرمایه‌گذاری روی یک ویکی دائمی بازگشت سرمایه خواهد داشت.
مؤثرترین سیستم‌ها احتمالاً در آینده ترکیبی (Hybrid) خواهند بود: استفاده از بازیابی سریع عامل‌محور برای واقعیت‌ها و یک ویکی سنتز شده برای نقشه‌برداری مفهومی. این ساختار تضمین می‌کند که عامل زمان خود را هر بار با شروع یک جلسه جدید، صرف «یادگیری مجدد» معماری سیستم نکند، در حالی که همچنان سرعت و دقت دسترسی مستقیم به منبع را برای کارهای روتین حفظ می‌کند.
به طور خلاصه، داده‌ها نشان می‌دهند که «ویکی LLM» جایگزینی برای RAG نیست، بلکه یک لایه مکمل است. این روش برای جست‌وجوهای ساده کندتر است چون یک مرحله واسط بین پرسش و منبع ایجاد می‌کند. با این حال، تنها روشی است که می‌تواند با موفقیت به پرسش‌هایی پاسخ دهد که جوابشان صراحتاً در منبع نوشته نشده، بلکه از رابطه بین چندین منبع استخراج می‌شود.
«رسیدهای» این آزمایش ثابت می‌کند که اگرچه ویکی از نظر توکن و زمان برای کارهای ساده گران‌تر است، اما قابلیت منحصر‌به‌فردی برای استدلال سطح بالا فراهم می‌کند که بازیابی بدون وضعیت قادر به بازسازی آن نیست. درس برای توسعه‌دهندگان عامل‌های هوش مصنوعی این است که استراتژی بازیابی را با بار شناختی تسک تطبیق دهند: از grep برای واقعیت‌ها و از ویکی برای خرد و حکمت استفاده کنید.
گام بعدی شما
- اگر از عامل‌های کدنویسی استفاده می‌کنید، برای تسک‌های جست‌وجوی سریع، ابزارهای grep-based را ترجیح دهید.
- برای پروژه‌های بلندمدت، ساختاری برای ثبت «تصمیمات معماری» توسط AI ایجاد کنید تا از تکرار جست‌وجوهای مشابه جلوگیری شود.
- در طراحی عامل‌های خود، تفکیک کنید که چه داده‌هایی نیاز به بازیابی آنی دارند و چه مفاهیمی باید در یک لایه دانش دائمی ذخیره شوند.
اما تأثیر این معماری بر مصرف حافظه در مدل‌های استدلالی حتی پیچیده‌تر است — به تحلیل ما درباره‌ی KV Cache مراجعه کنید.
گفتگو