جست‌وجوی وب در عامل‌های هوش مصنوعی از «تازگی» به «شواهد» منتقل شد

اگر عامل‌های هوش مصنوعی خود را برای مهندسی در محیط عملیاتی یا بررسی‌های حقوقی به کار می‌گیرید، یک لینک ساده در حباب چت دیگر برای بازرسی فنی کافی نیست. AWS در ۱۸ ژوئن ۲۰۲۶ اعلام کرد که قابلیت جستجوی وب اکنون در Amazon Bedrock AgentCore در دسترس است تا نحوه بازیابی داده‌های آنی توسط عامل‌ها از طریق درگاه AgentCore و با استفاده از پروتکل بافت مدل (Model Context Protocol یا MCP) تغییر کند.

مدل‌های زبانی بزرگ (LLM) ذاتاً با داده‌های قدیمی سروکار دارند؛ این یک نقص نیست، بلکه ماهیت این فناوری است. یک مدل آموزش می‌بیند، عرضه می‌شود و در نهایت از او درباره اتفاقی که دیروز رخ داده سؤال می‌شود. گاهی مدل پاسخ می‌دهد، گاهی نیمه‌دان است و گاهی با اعتمادبه‌نفس یک مهندس ارشد که شش ماه است سراغ سیستمی نرفته، پاسخ می‌دهد. به همین دلیل است که عامل‌ها به جستجوی وب نیاز دارند.

همان‌طور که در تحلیل‌های پیشین ما درباره امنیت مدل‌های بازمتن اشاره کردیم، دسترسی به داده‌های بیرونی همواره ریسک‌های امنیتی را بالا می‌برد. در به‌روزرسانی Bedrock AgentCore، هدف این است که عامل‌ها ابزاری مدیریت‌شده برای بازیابی نتایج وب، قطعات متن (snippets)، URLها، عناوین و تاریخ انتشار داشته باشند. نکته حیاتی این است که این فرآیند از طریق درگاه AgentCore رخ می‌دهد، بدون اینکه پرس‌وجو به یک ارائه‌دهنده جستجوی خارجی خارج از محیط AWS مشتری ارسال شود.

بسیاری از توسعه‌دهندگان به جستجوی وب به عنوان راهکاری برای «تازگی» (Freshness) نگاه می‌کنند تا شکاف بین تاریخ آموزش مدل و امروز را پر کنند. برای مثال، اگر مدل از آخرین تغییرات یک API یا یک هشدار امنیتی جدید بی‌خبر باشد، جستجو می‌کند. اما صنعت اکنون متوجه شده است که تازگی به معنای درست بودن نیست.

محدودیت‌های تازگی

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

• یافتن یک پست وبلاگی به‌روز اما نادیده گرفتن مستندات رسمی.
• استناد به صفحه بازاریابی در حالی که محدودیت واقعی در صفحه قیمت‌گذاری است.
• استخراج قطعه متنی از یک خبر که به‌روز است اما با منطقه، لایسنس یا محدوده انطباق (compliance) حساب کاربری خاص کاربر هم‌خوانی ندارد.

داده‌های تازه لزوماً درست، کافی یا قابل بازرسی نیستند. به همین دلیل است که متادیتاهای پیرامون نتایج جستجو به اندازه خود نتایج اهمیت دارند. URL منبع، عنوان، تاریخ انتشار و زمان بازیابی، جزئیات پیاده‌سازی نیستند، بلکه بخشی از «منشأ» (provenance) پاسخ هستند.

چرخش از «پایه گذاری» به «شواهد»

به نقل از تحلیل‌های فنی وب‌سایت dev.to، ارزش حیاتی به‌روزرسانی Bedrock AgentCore تنها در توانایی جستجو نیست، بلکه در ایجاد یک مرز عملیاتی است. وقتی یک عامل از ابزاری مدیریت‌شده استفاده می‌کند، خروجی از «مدل این‌طور گفت» به «عامل از این شاهد خاص استفاده کرد» تغییر می‌کند.

برای قابل‌اعتماد کردن این مسیر، نتایج جستجو باید به جای قطعات متن زودگذر، به عنوان «سوابق ماندگار» (durable records) تلقی شوند. در پاسخ به یک سؤال تفننی، شواهد می‌توانند گذرا باشند؛ اما برای کارهای مهندسی، بررسی‌های حقوقی، پشتیبانی مشتری یا پاسخ به حوادث امنیتی، شواهد باید چنان ماندگار باشند که بعداً قابل بازرسی باشند.

یک مدل شواهد مستحکم نیازمند ذخیره متادیتاهای زیر فراتر از یک جلسه (session) است:

• پرس‌وجوی دقیق اجرا شده توسط عامل
• URL منبع، عنوان صفحه و تاریخ انتشار
• برچسب زمانی دقیق بازیابی و رتبه‌بندی
• هویت ابزاری که برای جستجو استفاده شده است
• وظیفه مشخصی که نیازمند این شاهد بوده
• شناسه جلسه (Session ID) عامل

ریسک تصمیمات خودکار

تصور کنید عاملی یک درخواست تغییر کد (Pull Request) برای ارتقای یک وابستگی باز می‌کند چون «نسخه قدیمی تحت تأثیر یک آسیب‌پذیری اخیر است». اگر عامل صرفاً بگوید نسخه آسیب‌پذیر است، بازبین (Reviewer) دچار نقطه کور می‌شود. تغییرات کد کافی نیست؛ بازبین به کل مسیر شواهد نیاز دارد تا بفهمد آیا هشدار امنیتی بیش از حد کلی بوده، یا یک CVE مورد مناقشه است، یا تداخل نام بسته‌ها رخ داده است.

جستجوی وب وقتی منجر به تغییر کد یا تفسیر راهنمای حقوقی/امنیتی می‌شود، فعالیتی کم‌ریسک نیست. در این موارد، جستجو تبدیل به ورودیِ یک تصمیم خودکار می‌شود. به همین دلیل AWS جستجوی وب را به عنوان یک ابزار هدفمند در درگاه AgentCore قرار داده تا به جای یک «کانال جانبی جادویی»، ابزاری با دسترسی کنترل‌شده باشد.

پیاده‌سازی سطوح کنترل

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

• کدام عامل‌های خاص اجازه جستجوی وب دارند
• کدام مخازن یا محیط‌ها اجازه استفاده از این ابزار را دارند
• آیا پرس‌وجوها و پرامپت‌ها ثبت (log) می‌شوند یا خیر
• آیا اجازه داده می‌شود داده‌های مشتری در یک پرس‌وجو ظاهر شوند
• استفاده از لیست‌های سفید یا سیاه برای منابع
• آیا ابزار محتوای خام صفحه را برمی‌گرداند یا متادیتاهای ساختاریافته
• آیا نتایج برای بازپخش (replayability) کش می‌شوند

فراتر از «تئاتر استناد»

استنادات اغلب شبیه به یک «تئاتر» هستند؛ آن‌ها توهمات را نمایان‌تر می‌کنند اما دقت را تضمین نمی‌کنند. یک مدل ممکن است برای یک جمله اشتباه، به منبع درستی استناد کند، یا صفحه از زمان بازیابی تغییر کرده باشد. ممکن است قطعه متن، یک شرط حیاتی را حذف کرده باشد یا منبع استناد شده، صرفاً خلاصه‌ای از منبع دیگری باشد که هرگز بررسی نشده است.

راستی‌آزمایی واقعی نیازمند یک مدل شواهد ساختاریافته است که در آن ادعاها به شناسه‌های (ID) پایدار متصل باشند. این کار به تیم‌ها اجازه می‌دهد بین مستندات رسمی، پست‌های انجمن و دفترچه‌های راهنمای داخلی تفاوت قائل شوند. باید مشخص باشد چه زمانی عامل از شواهد وب استفاده کرده و چه زمانی به مستندات داخلی، حافظه یا جستجوی کد تکیه کرده است.

این موضوع هنگام تلاقی «پایه‌گذاری وب» با «بافت سازمانی» حیاتی است. یک عامل ممکن است نیاز داشته باشد یک اعلان عمومی AWS را با سیاست داخلی یک حساب کاربری، یا یادداشت انتشار Kubernetes را با نسخه خاص یک کلاستر ترکیب کند. حقیقت وب تنها یک جزء است؛ بخش سخت، حفظ مرزهای بین این انواع مختلف از حقایق است.

تغییر در فرآیند بازبینی

این چرخش، ماهیت بازبینی کد و اسناد را تغییر می‌دهد. بازبین‌ها از پرسیدن «آیا تغییرات کد درست است؟» به سمت پرسیدن «آیا شواهد زیربنایی درست بودند؟» حرکت می‌کنند.

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

ساخت یک مدل شواهد محدود

اگر در حال ساخت یک پلتفرم داخلی برای عامل‌ها هستید، اولویت باید یک «مدل شواهد محدود» باشد. هر نتیجه جستجو باید به یک رکورد شاهد با شناسه پایدار تبدیل شود. عامل باید به این رکوردها استناد کند، نه اینکه صرفاً URLها را در متن بچسباند.

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

در نهایت، تیم‌ها باید کیفیت شواهد را با ردیابی موارد زیر بسنجند:

• عامل‌ها بیشتر از کدام منابع استفاده می‌کنند
• کدام منابع به‌طور مداوم منجر به رد شدن کار می‌شوند
• کدام گردش‌های کاری بیش از حد به صفحات کم‌اعتبار تکیه دارند
• کدام عامل‌ها زمانی وب را جستجو می‌کنند که باید از مستندات داخلی استفاده کنند

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

گام بعدی شما

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

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